1. The Field of the Invention
The present invention relates to network communication technology. More specifically, the present invention relates to mechanisms for using an internal buffer other than the send queue to reduce acknowledgement related delays in acknowledgement-based reliable communication protocols.
2. Background and Related Art
Computing technology has transformed the way we work and play. Much of the functionality of computing systems is derived from the ability of computing systems to communicate one with another over a network. For example, e-mail, instant messaging, Web navigation, and many other common applications rely on network communication. In order to so communicate, it is important that the sending and receiving computing system follow compatible protocols governing communication.
Many protocols limit the amount of data that can be transmitted in a single packet. Accordingly, if a computing system is to send more data than is permitted in a single packet, then the computing system uses the protocol to break the send data into multiple packets having appropriate headers. For example, Transmission Control Protocol (TCP) and Internet Protocol (IP) packetize send data if needed.
Unfortunately, there are several realistic failure mechanisms whereby a packet transmitted on a network may never be received at its intended destination. However, some applications require a high degree of reliability when communicating with another computing system. In order to improve reliability of communications, some communication protocols use acknowledgement messages whereby the receiving computing system sends acknowledgement packets to the sending computing system to properly acknowledge receipt of one or more packets. The sending computing system considers the send-operation complete once the sending computing system receives one or more acknowledgements of receipt that collectively acknowledge all of the packets in the message.
Previously, reliable communication protocols had sent an acknowledgement packet for every packet sent. However, to reduce network traffic (and to give a chance to piggyback the acknowledgement on data in the reverse direction), commonly used reliable communication protocols, such as TCP, typically requires acknowledgement of every two packets, and even permits acknowledgement of more than two packets. Accordingly, when the receiving computing system receives a first packet since the last acknowledgement for a given connection (or the first packet since the connection was established), then the reliable communication protocol will typically have the receiving computing system wait for one or more other packets on the connection before an acknowledgment packet is sent.
However, sometimes, the single packet received since the last acknowledgement may be the last packet in a message, or the single packet received over the connection may be the only packet in the message. In either case, another packet for the message will not be received. To accommodate this common scenario, some reliable communication protocols such as TCP send an acknowledgement for a single packet if a subsequent packet has not been received over the connection for a certain amount of time whereby it appears that the single packet is the last or only packet for a message. The TCP implementation in Windows, for example, waits for 200 milliseconds on average since the last packet received before sending an acknowledgement message for a single packet. Other TCP implementations may wait for even longer.
This final waiting time is significant in terms of how long it takes to send a packet. In many cases, the final waiting time for the final packet is longer than the transmission time for all other packets in the message combined. Accordingly, the module or application that initiated the message has to wait this additional time before it can consider the send-operation complete.
One conventional way of reducing this wait time is to immediately write a message into an internal buffer, and then immediately return a send complete indication to the module or application that initiated the send. Packets are constructed from the internal buffer as they are ready to be sent. As packets are acknowledged, the data is removed from the internal buffer.
This conventional method has definite benefits. In particular, the calling module or application that made the send request is immediately returned a send complete message and thus may perform other actions. Unfortunately, the send complete indication is somewhat unreliable. After all, none or very little of the message may actually have been sent before the send complete indication is made. It may be that packets cannot be transmitted successfully. However, the calling application was informed of a successful send, and thus may take erroneous actions based on the false assumption of a successful send. In addition, the conventional method incurs significant processing and memory costs since all send data will be copied and stored by the transport protocol.
Accordingly, what would be advantageous are mechanisms in which the delay due to the final acknowledgement is reduced or even eliminated while still retaining reliability and performance.